These changes look good to me. I agree on removing the misleading warning - best not to confuse users by warning about normal operations.

@emersonknapp Thank you for your contribution and sorry for my late response.
This is certainly improvements comparable to how it was before.
Although I would like to give some "love" to the logic in implementation to make more clear.

I have some concern in regards to the API changes in particular to the has_next_file(bool reverse) and load_next_file(bool reverse).
After some consideration I think it will be better to create separate API for has_previous_file() and load_next_file()
You may argue that current implementation is better align with current implementation since we already have reverse flag on which we rely up on.

From one hand it look like easy and more straight forward in implementation in one place

However from another hand it's not very clear in another place where logic more sophisticated

if (timestamp < start_time && has_prev_file()) {
    // Check back a file if the timestamp is before the beginning of the current file
    load_prev_file(true);
    return seek(timestamp);
  } else if (timestamp > end_time && has_next_file()) {
    // Check forward a file if the timestamp is after the end of the current file
    load_next_file();
    return seek(timestamp);
  } else {
    // The timestamp lies in the range of this file, or there are no files left to go to
    storage_->seek(timestamp);
  }

When someone will try to comprehend this logic and will see construction like has_next_file(true) it's not really obvious that this method call really checking for existence of the previous file rather than next. And it will cause a lot of confusion and will have to keep in mind that next file is not really the next but previous even if name it as next. It's more error prone approach.

Also you can argue that it's made for the sake of the reducing code duplication in "next_/previous_" methods. I was trying to consider this argument as well and it looks like this not really the case. It will be a duplication of a few lines of code in load_next_file() and load_previous_file()

I also was thinking about performance impact for calling get_metadata from storage for each seek operation.

In current implementation at least in sqlite3 storage plugin this is pretty much expensive call.
We do request to the database for pulling out information about all topics and counting all messages in essence internally in db engine it will translates to iterating over each message give results from such SQL request.
I think we can optimize this place if we will readout and calculate values for metadata only once when we are opening storage and keep metadata in private member variable ready to be returned when needed by request from get_metadata() method.
Although there are one caveat in such approach. We need to take in to account situation when get metadata could be called for storage which was opened with read_write or append io_flag.
We need to readout metadata only if io_flag == READ_ONLY.
We can built in somewhere here

@emersonknapp Looks good enough to be merged with green CI.

Although it could be even better if address performance impact for calling get_metadata from storage for each seek operation.

In current implementation at least in sqlite3 storage plugin this is pretty much expensive call.
We do request to the database for pulling out information about all topics and counting all messages in essence internally in db engine it will translates to iterating over each message give results from such SQL request.
I think we can optimize this place if we will readout and calculate values for metadata only once when we are opening storage and keep metadata in private member variable ready to be returned when needed by request from get_metadata() method.
Although there are one caveat in such approach. We need to take in to account situation when get metadata could be called for storage which was opened with read_write or append io_flag.
We need to readout metadata only if io_flag == READ_ONLY.
We can built in somewhere here

@emersonknapp Thoughts? May be implement in follow up issue?